Web services runtime architecture

ABSTRACT

A runtime architecture for Web services utilizes a container driver to accept an invoke request for Web services. The container driver performs any necessary data binding/unbinding required to process the invoke request and associated message context, utilizing an appropriate plugin component. An interceptor receives the context information and modifies the message context for Web service compatibility. An invocation handler receives the formatted context information and passes parameters from the message context to the target of the request. The invocation handler processes values returned from the target and passes them to the container driver, which can formulate and return a response, along with the message context, to the client or protocol adapter.  
     This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

CLAIM OF PRIORITY

[0001] This application claims priority to U.S. Provisional PatentApplication No. 60/359,098, filed Feb. 22, 2002, entitled “WEB SERVICESRUNTIME ARCHITECTURE,” as well as U.S. Provisional Patent ApplicationNo. 60/359,231, filed Feb. 22, 2002, entitled “WEB SERVICES PROGRAMMINGAND DEPLOYMENT,” each of which is hereby incorporated herein byreference.

COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document containsmaterial which is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument of the patent disclosure, as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

FIELD OF THE INVENTION

[0003] The present invention relates to the implementation of webservices.

BACKGROUND

[0004] Web services are becoming an integral part of many applicationservers, with an importance that can rival HTTP or RMI stacks. Javastandards for Web services are being developed through the JavaCommunity Process. Businesses are building important applications on topof Web services infrastructures, such as is available in WebLogic Serverfrom BEA Systems of San Jose, Calif. Presently, however, there is nocomplete implementation of Web services upon which to build.

BRIEF SUMMARY

[0005] A system and method in accordance with the present inventionovercome deficiencies in the prior art by utilizing a runtimearchitecture for Web services. A container driver is used in thearchitecture for accepting an invoke request for Web services, such asfrom a protocol adapter. The container driver can perform any databinding and unbinding required to process the invoke request, utilizinga plugin component such as a Java binding codec, SOAP codec, XML codec,or custom codecs.

[0006] An interceptor can receive the context information for the invokerequest from the container driver and modify the message context to beused with Web services. An invocation handler can receive the contextinformation from the container driver after the message context has beenmodified by the interceptor. The invocation handler can pass parametersfrom the message context to the target of the request and process valuesreturned from the target. The invocation handler can then pass thesevalues to the container driver, such that the container driver canformulate a response to the invoke request. The response and messagecontext can then be returned to the client or protocol adapter.

[0007] Other features, aspects, and objects of the invention can beobtained from a review of the specification, the figures, and theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008]FIG. 1 is a diagram of a system in accordance with one embodimentof the present invention.

[0009]FIG. 2 is a diagram of a Web service container that can be usedwith the system of FIG. 1.

[0010]FIG. 3 is a diagram of a Web service client that can be used withthe system of FIG. 1.

DETAILED DESCRIPTION

[0011] Systems and methods in accordance with one embodiment of thepresent invention can overcome deficiencies in existing Web serviceimplementations by providing a more stable, complete implementation thatis suitable as an application integration platform.

[0012] A Web services architecture can allow for communication over anumber of transports/protocols. HTTP can continue to be a primarytransport mechanism for existing applications, while transportmechanisms such as SMTP, FTP, JMS, and file system mailboxes can also besupported.

[0013] Message formats such as SOAP 1.1 and 1.2 with attachments can beused as primary message formats. It is also possible to accept Webservice requests that are XML-encoded and submitted via HTTP posts. AWeb services architecture can support plugging in other message formatsand provide a mechanism for access to the raw message for user code.

[0014] A Web services architecture can utilize a stack that supports astandards-based default binding of fundamental XML data types supportedin various Web service platforms. An API can be used to allow otherbinding mechanisms to be plugged in. The binding to be used can bespecified on a per-operation basis.

[0015] Various security and messaging standards require a context orstate to be associated with Web service messages. A Web servicesarchitecture can support the processing of multiple message contexts,such as those related to security or conversation ID, and can offer usercode access to these contexts. Many of these contexts can be encodedinto a SOAP header, although it is also possible to include the contextsin the underlying protocol layer (e.g., cookies in HTTP) or in the bodyof the message (e.g., digital signatures). A Web services container canexplicitly process contexts associated with planned security featuresfor Web services.

[0016] A Web services stack can support a number of dispatch andsynchrony models. Dispatch to both stateless and stateful components canbe supported, using both remote procedure call (RPC) and messaginginvocation semantics. Synchronous and asynchronous processing ofrequests can also be supported. In particular, it can be possible toenqueue an incoming message, to enqueue an outbound message, and to makeasynchronous outbound calls. Enqueuing involves downloading files, oneat a time, from a queue.

[0017] A component such as a session EJB can be used to implementapplication-hosted Web services, such as for business logic. An API canbe provided for sophisticated users to integrate other types ofcomponents, even custom components, into a Web service mechanism. Thismay be used rarely, such as by developers who wish to build higher-levelfacilities and infrastructure on top of application-specific Webservices.

[0018] A Web services architecture should not preclude the embedding ofa Web service container in a lightweight server running in a morerestricted Java platform, such as J2ME/CDC. A very thin Web service Javaclient, such as less than 100 kb, can also be supported. Such anarchitecture should not preclude support for future Web servicestandards, such as JAX-RPC. However, due to the present lack of maturityand quality of Java Web Service standards, application-specific APIs canbe defined for the implementation of Web services.

[0019] A runtime Web services architecture can support both synchronousand asynchronous (“one-way”) RPC style Web services, such as may bebackended by an EJB. Message-style Web services can also be supported,which allow content to be submitted to and received from a JMSdestination. Endpoints can be supported in a transport-specific way.These endpoints can associate a transport-specific address with a Webservice. For instance, in HTTP a particular address can be associatedwith a Web service to be invoked. For SMTP an email address can beassociated with a Web service.

[0020]FIG. 1 shows the relationship of a Web container 108 and SMTPlistener 104 and a host server or Web service container 108, utilizingan architecture in accordance with one embodiment of the presentinvention. An HTTP protocol adapter 102 is shown in the Web container100. A protocol adapter for HTTP 102 is shown in a Web container 100,that can intercept a Web service invoke via HTTP from a Web servicesclient. A protocol adapter for SMTP 106 is also shown in an SMTPlistener 104, which can accept a Web service invoke via SMTP. Thisarchitecture allows for pluggability in a number of places.

[0021]FIG. 2 shows a diagram of the architecture of the Web servicecontainer 108 of FIG. 1. The HTTP protocol adapter 102 of the Webcontainer 100 is shown passing message context to, and receiving messagecontext from, a container driver 200. The container driver 200 receivesthe message context from the protocol adapter 102 and sends the messagecontext to the registered inbound interceptors 202, 204, 206. Afterextracting the operation parameters and performing any necessary databinding, such as by using a Java Binding codec 222, a SOAP codec 224, anXML codec 226, or a custom codec 228, the container driver 200 submitsthe operation request to the appropriate invocation handler 208, such asfor EJB 210 or JMS 212, or to a customized invocation handler 214. Afterreceiving data back from the invocation handler 208, the containerdriver 200 can perform any data unbinding using the appropriate codecs222, 224, 226, 228 and send the response to the outbound interceptors202, 204, 206. The container driver 200 can then return the response tothe protocol adapter 102. The protocol adapter, interceptors, andinvocation handler can each have access to an invocation context object216. The invocation handler 208 can also provide context access to thecomponent 218 to which it delegates, which can be contained in acomponent container 220.

[0022] A message context is a representation of a Web service invocationflowing through a container. A message context can contain a requestmessage, which is the Web service request. A message context can berendered into the canonical form of SOAP plus attachments. A responsemessage is the Web services response, or at least a placeholder for theresponse if the response has not been formulated yet. A response messagecan also be in the canonical form of SOAP plus attachments. Transportinformation can contain relevant information that is specific to thetransport over which the request came, and over which the response mustbe sent. For example, the transport information can contain the HTTPrequest and response streams for HTTP transport. An invocation contextcan also be used, which is described below.

[0023] A protocol adapter can be inserted into the subsystem of a hostserver. A protocol adapter can be responsible for processing incomingrequests for a particular transport/protocol, such as HTTP or SMTP. Thisallows the Web service container to process Web service messages invarious formats that are sent over multiple protocols. It will alsoallow the Web service container to reside in different kinds of servers.One condition for a protocol adapter is that the host server can supportthe protocol and that the message format can be converted into SOAPinternally. There are no known important message formats that cannot beexpressed via SOAP.

[0024] A protocol adapter can be responsible for identifying requests asWeb service messages, as well as routing the messages to a Web servicescontainer. If the protocol being used supports synchronous responses, aprotocol adapter can also receive the response data and return the datato the originator of the request. The protocol adapter can convert themessage to the original message format if it is not SOAP plusattachments. A protocol adapter can deal with any message context thatis required by the container, such as a conversation ID, and istransmitted at the protocol level, such as cookies in HTTP. The protocoladapter can propagate the message context to and from a Web servicescontainer.

[0025] The actual implementation of protocol adapter functionality candepend on the architecture of the host server, as well as the way thatthe protocol is hosted in the server. For example, the functions of aprotocol adapter can be implemented in part by the normal function of aWeb container for an HTTP protocol. Due to the dependency of protocolprocessing on server internals, there may not be many public protocoladapter APIs.

[0026] An invocation context can be used, which is an inheritablethread-local object that can store arbitrary context data used inprocessing a Web service request. The context can be available fromvarious components of the architecture involved in the processing of therequest and response. Typical data that might be stored in such acontext are a conversation ID, a message sequence number, and a securitytoken. A particular invocation handler can choose to make the invocationcontext available to the target component. This can allow applicationcode to read and write to the invocation context.

[0027] An architecture can utilize interceptors. Interceptors areplugins that can provide access to inbound and outbound Web servicemessages. An interceptor API can be public, and an implementation of aninterceptor API can be part of a Web service application. An interceptorcan modify SOAP messages as required. An interceptor can also read andwrite information on the invocation context. Interceptors can beassociated with either operation, or with the namespace of the messagebody.

[0028] There are different types of interceptors. Header handlers can beused, for example, which operate only on message headers. Headerhandlers must declare which message headers they require so that theheader information can be exposed, such as in the W3C Web servicedefinition language (WSDL) generated for the Web service. Flow handlers,on the other hand, can operate on full message content. Flow handlers donot require a declaration of which message parts are processed, and donot result in the existence of any additional information in thegenerated WSDL. Application developers may use header handlersprimarily, while business units that are building infrastructure on topof an application server may choose to use flow handlers. Both APIs,however, can be public.

[0029] XML serialization and deserialization plugins can be supported,which can handle the conversion of method parameters from XML to Javaobjects and return values from Java to XML. Built-in mappings for theSOAP encoding data types can be included with an application server. Theprocessing of literal XML data that is sent outside any encoding canalso be supported, as well as Apache “Literal XML” encoding. Users canalso implement their own custom data type mappings and plug thosemappings in to handle custom data types.

[0030] A container driver can be used with a Web services architecturein accordance with one embodiment of the present invention. A containerdriver can be thought of as the conceptual driver of a Web servicecontainer. A container driver can implement the process flow involved inperforming a Web service request.

[0031] For RPC Web services hosted on an application server, the defaulttarget of a Web service invocation can be an EJB instance. Formessage-style Web services, the default target can be a JMS destination.In certain cases, it may be desirable to allow other components orsubsystems as targets. People can build middleware infrastructure on topof application servers to require this functionality. Therefore, aninvocation handler API can be supported to allow the Web servicerequests to be targeted at different components besides EJBs.

[0032] An invocation handler can insulate the Web service container fromdetails of the target object lifecycle, transaction management, andsecurity policies. The implementer of an invocation handler can beresponsible for a number of tasks. These tasks can include: identifyinga target object, performing any security checks, performing theinvocation, collecting the response, and returning the response to thecontainer driver. The implementer can also be responsible forpropagating any contextual state, such as a conversation ID or securityrole, as may be needed by a target component.

[0033] A protocol adapter can perform the following steps in oneembodiment. The protocol adapter can identify the invocation handler ofthe target component deployment, such as a stateless EJB adapter. Theprotocol adapter can identify any additional configuration informationneeded by the invocation handler to resolve the service, such as theJNDI name of a deployed EJB home. This information can be in thedeployment descriptor of the protocol adapter deployment, such as aservice JNDI name, and/or the information could be in the headers orbody of the request or in the protocol.

[0034] A protocol adapter can identify the style of a Web servicerequest, such as one-way RPC, synchronous RPC, or messaging. Ifnecessary, a protocol adapter can convert an incoming request messageinto the SOAP with attachments canonical form. A protocol adapter cancreate a message context containing the request, a placeholder for aresponse, information about the transport, and information about thetarget invocation handler. A protocol adapter can also dispatch messagecontext configuration to the Web service container.

[0035] A container driver can manage the flow of processing in thecontainer. The container driver can receive the message context from theprotocol adapter and, in one embodiment, sequentially performs thefollowing steps. The container driver can dispatch to registered inboundinterceptors, extract operation parameters, and perform data binding.The container driver can submit the operation request to the appropriateinvocation handler, which can delegate the invoke to a target object.The container driver can receive a response from the invocation handler,possibly including a return value. If there is a return value, thecontainer driver can perform data unbinding. If the synchrony model isrequest-response, the container driver can formulate a SOAP response.The response can be dispatched to registered outbound interceptors andreturned to the protocol adapter for return to the caller.

[0036] The protocol adapter can return the SOAP response to the caller,converting the response back to the original message format if it wasnot SOAP. The protocol adapter, interceptors, and invocation handler caneach have access to the invocation context object. Any necessary stateneeded during request processing can be propagated through this context.The invocation handler can also provide access to the context, such asto the component to which the invocation handler delegates.

[0037] An invocation handler that has been targeted to process an invokecan receive the following data from the container: the operation name,an array of Java Object parameters, any invocation handler configurationdata, and the invocation context. The invocation handler can perform theinvocation and return an array of Java Object return values.

[0038] An invocation handler can perform the following steps for onemethod in accordance with the present invention. A target object can beidentified for the invocation. The invocation can be performed bypassing the parameters to the target. The invocation context object canbe provided to the target. Also, a transaction, security, orcomponent-specific context can be passed to the target object. Anyreturn value(s) from the target can be processed and returned to thecontainer driver.

[0039] An API can be used for invocation handlers. Invocation handlerscan be configured when the protocol adapter is deployed. For example,the HTTP protocol handler can be a Web application.

[0040] Many types of built-in invocation handlers can be used. One suchinvocation handler is an EJB invocation handler. EJB invocation handlerscan require a service identity, such as the JNDI name of the EJB home,and possibly a conversation ID, which can be extracted from a cookie, inthe case of stateful EJB targets. The body of the request can indicatethe operation name that will be mapped to the proper method call on theEJB.

[0041] A stateless EJB invocation handler can be used to dispatch Webservice invokes to an EJB. This handler can require the JNDI name of thestateless EJB home. The handler can obtain an instance of the EJB andcan dispatch the invoke and return the return value, if there is one.

[0042] A stateful session EJB invocation handler can be used to dispatchinvokes to a stateful session bean. The handler can require the JNDIname of the stateful EJB home, as well as a conversation ID, which canbe extracted from the message. The default approach for HTTP can be toextract the conversation ID from a cookie in the HTTP protocol handlerand to put it in the invocation context under a documented name. If thisdefault behavior is not suitable, the developer can provide a headerhandler that extracts the conversation ID from message headers andplaces the ID in the invocation context.

[0043] A stateful session bean (SFSB) invocation handler can maintain atable of mappings between a conversation ID and EJB handles. If noconversation ID is found, the stateful EJB invocation handler can createa new conversation ID, a new session bean instance, and can add itshandle to the mapping table. The invoke can then be dispatched to theSFSB referenced by the handle.

[0044] A JMS invocation handler can dispatch the body of a SOAP messageto a JMS destination. The handler can require the JNDI name of thedestination, the JNDI name of the connection factory, and thedestination type.

[0045] The configuration of protocol handlers can involve specifying themapping between Web service endpoint URIs, such as URLs in the case ofHTTP or email addresses in the case of SMTP, and the name of aninvocation handler. A particular invocation handler can requireadditional configuration information, such as the JNDI-name of a targetEJB deployment.

[0046] An HTTP protocol handler can be a special Web application that isautomatically deployed when a Web archive file (WAR) is deployed. TheURL mappings to invocation handlers can be extracted from the WSP (“Webservice provider”) description of the Web service. An HTTP protocolhandler can map HTTP headers to the invocation context and can attemptto extract a conversation ID from an HTTP cookie, if one is present. AnSMTP Protocol Handler can also be utilized.

[0047] An HTTP-based Web Service can be packaged in and deployed from aJ2EE WAR that is contained inside a J2EE Enterprise Archive File (EAR).The WAR can contain a Web service WSP document, which defines a Webservice. The WSP can describe the shape of the Web service and how theimplementation maps to backend components. A WSP can be referenced inthe URL of a Web service, like a JSP. It can also allow reference touser-defined tags, like a JSP which can integrate user-developedfunctions into the definition of the Web service. It can also supportthe scripting of Web service functions. Unlike a JSP, however, a WSP maynot compile down to a servlet. The WSP can be directly utilized by theWeb service runtime.

[0048] The remaining contents of the EAR can include EJB-JARs or otherclasses that are part of the implementation of the Web service.

[0049] A Web container can manage the deployment of HTTP WSPs in asimilar manner to JSPS. There can be a default WSP servlet registeredwith each Web application that intercepts requests for WSPs. The defaultservlet can then redirect each request to the appropriate WSP handler.

[0050] A user can open a Web application in a console, or in a consoleview, and can view the names of the WSPs that are part of that Webapplication. It can be necessary to modify an MBean, such asWebAppComponentMBean, on order to provide a list of WSPs.

[0051] Java-based Web services client distributions can be used withservices hosted on many different platforms. A full set of featuressupported on a client can include:

[0052] HTTP protocol with cookie support

[0053] SOAP 1.2 with attachments

[0054] JAX-RPC client API, including synchronous and “one-way” RPCinvokes

[0055] Header Handler and Flow Handler API

[0056] Message-style Web service client API

[0057] Support for “dynamic mode” (no Java interfaces or WSDL required)

[0058] Support for “static mode” (Java interfaces and service stubsrequired)

[0059] The full set of SOAP encodings+Literal XML+support for customencodings

[0060] Security support:

[0061] 128-bit two-way SSL

[0062] Digital Signatures

[0063] XML Data Encryption

[0064] There is an inherent tradeoff between the “thinness” of a clientand the richness of features that can be supported. To accommodatecustomers with differing needs regarding features and footprint, severaldifferent client runtime distributions can be offered with varyinglevels of features.

[0065] A J2SE Web Service client, which can have a footprint of around 1MB, can be full-featured. SSL and JCE security functions can be includedin separate jars. This client can run in regular VM environments, suchas those hosting application servers. A J2ME/CDC thin client can have alimited set of features, but can be designed to run in a J2ME CDCprofile on devices. A JDK 1.1 thin client can have a limited set offeatures, but can be intended to run in JDK 1.1 virtual machines,including those hosting applets.

[0066] Client distributions can include classes needed to invoke Webservices in “dynamic” mode. Utilities can be provided to generate staticstubs and Java interfaces, if given WSDL service descriptions.

[0067] A Java™ 2 Platform, Standard Edition (J2SE) Web service clientcan be a standard, full-featured client, which can be intended to runinside an application server. The client can be included in a regularserver distribution, and can also be available in a separate jar so thatit may be included in other J2EE or “fat client” JVMs. There may be nosize restriction on this client. The client can utilize JDK 1.3.

[0068]FIG. 3 shows an architecture of the client-side for a J2SE WebService client 318 in accordance with one embodiment of the presentinvention. The client is closely related to the Web service container.The client can be an embeddable Web service container that can run inlighter weight servers. This can allow asynchronous callbacks to beinvoked on the client.

[0069] In FIG. 3, the HTTP protocol adapter 102 of the Web container 100is shown passing message context to, and receiving message context from,a container driver 300. The container driver 300 can receive messagecontext from the protocol adapter 102 and send the message context tothe registered inbound interceptors 302, 304, 306. After extractingperforming any necessary data binding or unbinding, such as by using aJava Binding codec 310, a SOAP codec 312, an XML codec 314, or a customcodec 316, the container driver 300 can return the data to the clientstub 308. If receiving invoke data from the client stub 308, thecontainer driver 300 can perform any data binding or unbinding using theappropriate codecs 310, 312, 314, 316 and send the invoke request to theoutbound interceptors 302, 304, 306. The container driver 300 can thensend message context for the invoke to the protocol adapter 102.

[0070] The foregoing description of preferred embodiments of the presentinvention has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many modifications andvariations will be apparent to one of ordinary skill in the art. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical application, therebyenabling others skilled in the art to understand the invention forvarious embodiments and with various modifications that are suited tothe particular use contemplated. It is intended that the scope of theinvention be defined by the following claims and their equivalence.

What is claimed is:
 1. A runtime architecture for Web services, comprising: a container driver for accepting an invoke request for Web services, said container driver adapted to perform any data binding and unbinding required to process the invoke request; an interceptor adapted to receive the context information for the invoke request from said container driver and modify the message context to be used with Web services; an invocation handler for receiving context information from said container driver after the message context has been modified by said interceptor, said invocation handler adapted to pass parameters from the message context to the target of the request and process values returned from the target, the invocation handler adapted to pass the values to the container driver such that the container driver can formulate a response to the invoke request.
 2. A system according to claim 1, further comprising a protocol adapter for intercepting an Web service invoke request and passing the Web service invoke request to said container driver.
 3. A system according to claim 2, wherein said protocol adapter can convert the format of an invoke request and create a message context containing the invoke request.
 4. A system according to claim 1, further comprising a plugin component to be used by said container driver to perform any data binding and unbinding.
 5. A system according to claim 4, wherein said plugin component is selected from the group consisting of Java binding codecs, SOAP codecs, XML codecs, and custom codecs.
 6. A system according to claim 1, further comprising an invocation context for storing arbitrary context data useful in processing the Web request, said invocation context available to at least one of said interceptor and said invocation handler.
 7. A system according to claim 1, wherein said interceptor is selected from the group consisting of header handlers and flow handlers.
 8. A system according to claim 1, wherein said invocation handler manages security policies, transaction management, and target object life cycle for the request.
 9. A system according to claim 1, further comprising a Web service container for hosting said container driver, said interceptor, and said invocation handler.
 10. A system according to claim 1, further comprising a target object to which said invocation handler can delegate processing the invoke request.
 11. A method for supporting Web services, comprising: receiving an invoke request for Web services to a container manager; formatting message context for the invoke request to be used with Web services; doing data binding on the message context; processing the request using an invocation handler and generating response data; unbinding the message context containing the response data; and reformatting the message context for responding to the invoke request.
 12. A method according to claim 11, further comprising intercepting an invoke request from a Web services client using a protocol adapter and generating message context for the invoke request to be sent to the container manager.
 13. A method according to claim 11, wherein said step of formatting message context comprises using an interceptor to format the message context.
 14. A method according to claim 11, wherein said step of doing data binding on the message context comprising using a codec selected from the group consisting of Java Binding codecs, SOAP codecs, XML codecs, and custom codecs.
 15. A method according to claim 11, further comprising storing arbitrary context data for use in processing the invoke request.
 16. A method according to claim 11, further comprising managing life cycle, transaction, and security information for the processing of the invoke request.
 17. A method according to claim 11, further comprising delegating the processing of the invoke request to a target object.
 18. A computer-readable medium, comprising: means for receiving an invoke request for Web services to a container manager; means for formatting message context for the invoke request to be used with Web services; means for performing data binding on the message context; means for processing the request using an invocation handler and generating response data; means for unbinding message context containing the response data; and means for reformatting the message context for responding to the invoke request.
 19. A computer program product for execution by a server computer for supporting Web services, comprising: computer code for receiving an invoke request for Web services to a container manager; computer code for formatting message context for the invoke request to be used with Web services; computer code for performing data binding on the message context; computer code for processing the request using an invocation handler and generating response data; computer code for unbinding message context containing the response data; and computer code for reformatting the message context for responding to the invoke request.
 20. A system for supporting Web services, comprising: means for receiving an invoke request for Web services to a container manager; means for formatting message context for the invoke request to be used with Web services; means for performing data binding on the message context; means for processing the request using an invocation handler and generating response data; means for unbinding message context containing the response data; and means for reformatting the message context for responding to the invoke request.
 21. A computer system comprising: a processor; object code executed by said processor, said object code configured to: receive an invoke request for Web services to a container manager; format message context for the invoke request to be used with Web services; perform data binding on the message context; process the request using an invocation handler and generating response data; unbind the message context containing the response data; and reformat the message context for responding to the invoke request.
 22. A computer data signal embodied in a transmission medium, comprising: a code segment including instructions to receive an invoke request for Web services to a container manager; a code segment including instructions to format message context for the invoke request to be used with Web services; a code segment including instructions to perform data binding on the message context; a code segment including instructions to process the request using an invocation handler and generating response data; a code segment including instructions to unbind the message context containing the response data; and a code segment including instructions to reformat the message context for responding to the invoke request. 